¿Cuándo elegirías `switchMap`, `concatMap`, `mergeMap` o `exhaustMap` en un caso real de UI?

"¿Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI?" toca un punto muy concreto de Angular: cómo tomar decisiones de asincronía sin esconder el problema bajo una abstracción vistosa.

Una respuesta senior se nota cuando nombras qué riesgo quieres reducir con asincronía en Angular para "Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI", qué concesión aceptarías frente a rxJS y qué comprobarías antes de extender la decisión a todo el sistema.

Qué evalúa el entrevistador

• Si distingues qué parte de "Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI" pertenece a asincronía y cuál debería resolverse en rxJS.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si sabes ubicar efectos, limpiezas, cancelación y propagación de errores sin contaminar la parte declarativa del código.

Respuesta sólida

• Distingue qué parte puede seguir siendo pura y qué parte necesita sincronizarse con el mundo exterior.
• Describe cómo controlarías suscripciones, cancelación, reintentos o cierre de recursos para que el componente no acumule efectos zombis.
• Si hay asincronía, aclara qué harías con estados intermedios, errores y cambios rápidos de entrada.

Compromisos y errores comunes

• El error habitual es usar efectos para derivar datos que podrían calcularse de forma pura o para tapar un mal diseño de dependencias.
• Sin cancelación ni limpieza es muy fácil dejar trabajo en vuelo, respuestas tardías o cierres obsoletos.

Ejemplo de código

Este fragmento sirve para bajar "Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI" a código ejecutable y mostrar qué decisiones conviene hacer explícitas cuando asincronía empieza a cruzarse con rxJS.

import { HttpInterceptorFn } from '@angular/common/http';
import { catchError, throwError } from 'rxjs';

export const authInterceptor: HttpInterceptorFn = (request, next) => {
  const authenticatedRequest = request.clone({
    setHeaders: { Authorization: 'Bearer token-demo' },
  });

  return next(authenticatedRequest).pipe(
    catchError((error) => {
      console.error('Error HTTP', error.status);
      return throwError(() => error);
    }),
  );
};

Fíjate en que el ejemplo deja claras las fronteras de "Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI", nombra los estados relevantes y evita trabajo implícito que luego cuesta depurar.

Ejemplo o caso real

Yo lo bajaría a un escenario reconocible de Angular: una pieza donde "Cuándo elegirías switchMap, concatMap, mergeMap o exhaustMap en un caso real de UI" aparece de forma recurrente, ya ha dejado señales en revisión o en soporte y mezcla asincronía con rxJS. Si la decisión mejora claridad, observabilidad y velocidad de cambio en ese trozo, entonces merece escalarla; si no, la dejaría local y documentada.

Frase corta de entrevista

Primero aclaro qué problema resuelvo con asincronía y luego elijo la técnica; no al revés.